Always make tuple elements a coercion site

Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:

```rust
((),) = (loop {},);
```

With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.

Fixes rust-lang#112856

r? BoxyUwU

…r=RalfJung

miri/const eval: support `MaybeDangling`

r? RalfJung

…ete, r=fee1-dead,Nadrieril

stop marking `deref_patterns` as an incomplete feature

This PR removes the `incomplete_feature` warning for `deref_patterns`. The reason given for this in the tracking issue (rust-lang#87121) was
> Per policy, the `incomplete_feature` is supposed to stay on until the feature has an accepted RFC. We're slowly working on writing up that RFC so it'll take some more time unfortunately.
>
> I don't know of any compiler crashes it causes today. The feature should be pretty usable.

However, I could not find any evidence of such a policy. The [lint documentation](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features) for `incomplete_features` also only mentions features that are more likely to cause errors.
There are also many other features without an RFC that are not considered incomplete, e.g. `macro_metavar_expr_concat`, `negative_impls` or `yeet_expr`.
The feature does not cause any known ICEs either.

The concrete motivation is to use this feature to replace `box_patterns` in the compiler and pave the way towards removing that legacy feature.

…ng-zst, r=RalfJung

fix ICE in `const_c_variadic` when passing ZSTs

fixes rust-lang#153351
r? RalfJung

There was a mismatch between the caller and callee ABI where the caller does not pass ZST arguments, but the callee does expect them. Because ZSTs don't implement `VaArgSafe` the program must already be invalid if this comes up.